早上開三個 agent run，很容易讓人有一種錯覺。
一個去修測試，一個去整理 API 回傳格式，一個去把舊元件搬到新的資料流。你去開會，吃飯，處理 Slack，晚上回來看結果。三個 run 都交了東西，diff 也不算醜，summary 寫得比某些人類同事還清楚。
看起來像省下三段時間。
其實你只是把三段工時延後到晚上驗收。
這是 coding agent 開始真正進團隊流程後，最容易被低估的成本。不是 token，也不是模型訂閱費，而是一批看不見的工時突然出現在你的 repo 裡。它們需要排隊、授權、驗收、合併、回滾，有些還要被丟掉。
如果團隊還用「聊天工具」的心態理解 agent，這件事一定會失控。
Autocomplete 的世界很單純。它補一句，你接受或拒絕。Chat assistant 的世界也還算好懂。你問問題，它回答，你把有用的部分拿走。
但現在的 agent workflow 比較像委派一個 runtime。
它會讀 repo，查錯誤，改檔案，跑命令，嘗試修測試，最後交回一包看似完整的工作。它不是在旁邊建議一句 code，而是在你離開鍵盤時繼續做事。
這個轉變很大。
以前你管理的是互動。現在你管理的是工作。互動可以靠記憶和直覺處理，工作需要排程、範圍、權限、紀錄和驗收標準。
很多團隊的問題就卡在這裡。他們買了 agent 工具，卻沒有把 agent work 當成正式工作流的一部分。於是每個人都用自己的方式派工，每個 run 都有自己的口頭規則，最後只剩下一堆 diff 和一句「看起來可以」。
這不是自動化。
這是把流程債換成 review 債。
如果 agent 都會開 PR、掛 bot label、留下完整紀錄，那事情還比較簡單。
真實世界通常不是這樣。
有人在本機叫 agent 修完，再自己 commit。有人讓 agent 先分析 issue，真正修改由人類手動完成。有人把 agent 產出的 patch 拆開，塞進不同 commit。也有人只用 agent 查檔、跑測試、整理錯誤訊息，最後 repo 裡完全看不出來。
所以你不能只問：「這週有幾個 AI PR？」
更好的問題是：「這週有哪些工程判斷，實際上有 agent 參與？」
這兩個問題差很多。
前者只看最後交付物。後者會逼你面對 agent work 的真實形狀：它可能藏在 commit message、設定檔、CLI log、本機 session、review comment、CI 修補紀錄裡。你如果不刻意收集，根本看不見。
看不見就不能管理。
你以為某個模組還是完全由熟悉的人類維護，實際上 agent 已經常常在那裡改測試、改 migration、改 build 設定。你以為只有低風險工作交給 agent，結果它其實讀過 private repo、跑過內部命令、拿過開發者 token。
這不是要恐嚇大家不要用 agent。
剛好相反。你真的要用，才更需要知道它在哪裡做了事。
很多團隊會用一句話安慰自己：「最後都有 human review。」
我覺得這句話太便宜。
Human review 很重要，但它不是保險。Reviewer 沒有無限時間，也不會自動知道 agent 之前做過哪些嘗試。當 diff 合理、測試 pass、summary 寫得很順，reviewer 很容易只檢查表面。
Agent 最危險的地方不一定是它寫出明顯錯的 code。
更麻煩的是它很會交出一個合理的故事。它說自己修了 edge case，補了測試，沒有碰到行為邊界。這些話看起來像證據，其實只是敘述。
真正的證據是另一回事。
跑過哪些命令？哪些沒跑？為什麼沒跑？改動範圍跟原本授權是否一致？有沒有碰到 authentication、payment、permission、data retention 這類不該順手重構的地方？如果 agent 做過幾次失敗嘗試，最後留下的 diff 有沒有把中間風險一起清掉？
沒有這些資訊，human in the loop 只是把責任推給一個很忙的人。
Agent 最容易被濫用的能力，就是平行跑。
因為它看起來太便宜了。開一個 run 幾乎沒有心理負擔。開五個也只是多等一下。問題是，產出會在同一時間回來，而你的 review capacity 沒有因此變成五倍。
所以我會先把 agent work 分成兩類。
低風險、可回滾、驗收清楚的任務，可以平行。
例如補測試、修 typo、整理文件、把已知錯誤訊息導向更明確的 copy、針對單一檔案做小範圍重構。這些任務的共同點是 scope 小，失敗成本低，驗收命令明確。
高風險任務不要隨便平行。
權限模型、付款流程、資料刪除、身份驗證、跨模組重構、部署腳本、package publishing，這些東西不是不能交給 agent，而是不能用「你先跑跑看」的心態交出去。這類工作至少要先有計畫、邊界和停損點。
比較務實的做法是建立一個很小的 queue rule：
這些規則不需要一開始就很漂亮。
先有，比沒有強太多。
Agent run 不能是匿名工時。
每個 run 至少要有一個 owner。不是「誰按下按鈕」而已，而是誰負責定義 scope、看結果、決定合不合、必要時丟掉。
這件事聽起來很基本，但很多混亂都從這裡開始。
一個人開了 agent run，另一個人看到 PR 幫忙 review，第三個人合併，第四個人在 production 發現問題。最後大家回頭看，沒有人真的知道當初那個 run 的限制是什麼。
我會要求每個 agent run 留下六件事：
這不是官僚。
這比較像收據。你不一定每天都會看，但出事時你會很慶幸它存在。
Vibe coding 最迷人的地方，是它讓人很快做出一個能跑的東西。
這很好。很多內部小工具、一次性腳本、prototype，本來就不值得用大型流程處理。
但有一條線要畫清楚：一旦那個東西開始被別人使用，尤其是碰到登入、檔案、付款、公司資料或客戶資料，它就不再只是你的本機實驗。
Agent 產出的 code 也一樣。
在本機跑一次可以，不代表能進 production。Demo 看起來順，不代表 threat model 存在。測試 pass，不代表資料保留、權限邊界和錯誤處理都被想過。
這裡最危險的不是 agent 寫錯，而是人類太快把「能跑」解讀成「能交付」。
所以高風險 agent work 的 acceptance contract 要更硬一點。至少要問：
這些問題跟 prompt 技巧無關。
它們是工程責任。
我不相信「agent 會讓工程流程消失」這種說法。
它會讓某些工作變快。很快。快到你原本靠直覺管理的流程突然不夠用了。
以前一個工程師一天只能做一兩件像樣的修改，所以 review、溝通和驗收的壓力還被人的速度限制住。現在一個人可以同時委派多個 agent run，晚上拿回一堆半成品、可用成品和看似可用的危險成品。
真正成熟的 agent workflow，不是讓工程師不用負責。
它是讓每一段被委派出去的工時都能被找回來、看懂、驗收，必要時丟掉。
所以我看一個團隊會不會用 coding agent，不會只看它用了哪個模型，也不會只看它一週產出多少 diff。
我會看更無聊的東西。
它有沒有 queue。每個 run 有沒有 owner。權限邊界有沒有寫下來。驗收命令是不是清楚。高風險任務會不會先停下來要求人類判斷。失敗的 agent work 會不會被回收，而不是默默混進下一次修改。
Code 寫得出來，只是開始。
看不見的工時管得住，agent 才真的進入工程流程。
ryanvale
iThome鐵人賽
看影片追技術